Will take a longer look next week!

A few quick thoughts:

• What is the intended use case of LMS? LMS-OTS is fairly clear, this is to be used with the default ephemeral signing code path (though maybe it'd be worth explicitly stating that this should be selected only for this case). When would we recommend someone use LMS? For self-managed keys where the signer keeps track of usage?
• "is it this repo/doc's responsibility to explain the complexity of hash-based schemes (especially non-OT ones)" - This is a great question. I want to avoid as many footguns as possible. If LMS-OTS has a clear, safe use case, then we should constrain it to only that use case (in practice, this will just be in a comment, but maybe it can be enforced by disallowing the algorithm in services, or at least requiring some flag-based acknowledgement of the risks).
• For parameter selection, has anyone given suggestions so far? I can ask Google's ISE Crypto team. Has NIST?

Another thought, should we put PQ algs into a separate experimental enum which has no guarantees with respect to breaking changes? That may also signal these are a work in progress.

• What is the intended use case of LMS? LMS-OTS is fairly clear, this is to be used with the default ephemeral signing code path (though maybe it'd be worth explicitly stating that this should be selected only for this case). When would we recommend someone use LMS? For self-managed keys where the signer keeps track of usage?

That's my understanding of the use case, but I'm just the lowly implementer 🙂. @tpletcher-hpe might be able to offer some additional context (here or on Slack; I can set that chat up).

If LMS-OTS has a clear, safe use case, then we should constrain it to only that use case (in practice, this will just be in a comment, but maybe it can be enforced by disallowing the algorithm in services, or at least requiring some flag-based acknowledgement of the risks).

This makes sense to me -- the clear, safe case for LM-OTS is keyless signing, which should be relatively misuse-resistant so long as the Sigstore client always generates a new keypair per signing operation.

• For parameter selection, has anyone given suggestions so far? I can ask Google's ISE Crypto team. Has NIST?

RFC 8554 has some parameter recommendations, including "top-level" recommendations for HSS (constructed on LMS) based on different tree depths and signing volume/longevity assumptions. All of those recommendations have reasonable security margins, but unfortunately aren't easy to generalize (since some clients may only need a key-tree that's valid for a few minutes, while another might need one that's valid for decades).

Another thought, should we put PQ algs into a separate experimental enum which has no guarantees with respect to breaking changes? That may also signal these are a work in progress.

That sounds reasonable to me. @tetsuo-cpp and @ret2libc: do you think having these in a separate enum would pose an integration challenge?

That sounds reasonable to me. @tetsuo-cpp and @ret2libc: do you think having these in a separate enum would pose an integration challenge?

I think it would be ideal to treat them as the same type, otherwise integration might become harder. If we can keep them separate while still treating them the same type on the Go-side (and other languages as well, actually), then I'm ok.

I think it would be ideal to treat them as the same type, otherwise integration might become harder. If we can keep them separate while still treating them the same type on the Go-side (and other languages as well, actually), then I'm ok.

Hmm, this might be hard without a layer of wrapper types in between. Given that enum variants are "cheap" and that nothing else uses KnownSignatureAlgorithm yet, maybe we could add these to the same enum but explicitly prefix them as EXPERIMENTAL_... to emphasize that they aren't considered fully recommended yet?

Thoughts @haydentherapper?

Given that enum variants are "cheap" and that nothing else uses KnownSignatureAlgorithm yet, maybe we could add these to the same enum but explicitly prefix them as EXPERIMENTAL_... to emphasize that they aren't considered fully recommended yet?

I'd prefer that idea also. If they're captured in separate enums, we'll have to wrap the enums behind an interface or something which will be messy in my opinion.

That sounds good with me.

Yes, EXPERIMENTAL prefix is the better option. When the algorithms are stable, we can mark the experimental field with [deprecated = true] and create a new entry for the stable one. This gives us a neat transition period.

But I still want to raise the question of how KnownSignatureAlgorithm should play with PublicKeyDetails.

The PublicKeyDetails today conflates two things, signature algorithm and encoding (on purpose to minimize footguns).
The PublicKeyDetails are used for rekor and the ct log as an example.

Wouldn't it make sense to only use that enum to capture the use-case here too (i.e add new experimental algorithms)? From a clients side perspective I'm kind of scratching my head a little, what's the intent of KnownSignatureAlgorithms when the algorithm can not be communicated to the client, and it can signal an algorithm we can't properly provide a public key for? (we can technically of course, but not as the protos are defined today).

Or is the idea for this to be a list of valid signature algorithms for the clients, i.e what is allowed to use for a client in their signing cert, or when signing a rekord to be pushed to Rekor? With a list here, we could reference from Fulcio or Rekor what algorithms they support?

Rewritten to extend PublicKeyDetails instead, PTAL @haydentherapper @kommendorkapten!

Can you update the PR title to note the RSA scheme additions?

Done!

Thanks, good to see this. My preference is to remove the PCS1 encoding for RSA, then we are ready to merge.

Thanks, good to see this. My preference is to remove the PCS1 encoding for RSA, then we are ready to merge.

Done!